The present invention relates to networking and communications technology, and more particularly to multicasting information from a source node to one or more destination nodes in a digital communications network.
Digital communications networks, such as the Internet, are well-known systems for permitting information stored at one location to be distributed to one or more users situated at geographically different locations. The information (also referred to herein as a “message”) can take any of a number of forms including, but not limited to, text, still image, audio, and video information.
While it is not unusual to use a digital communications network to move information (e.g., a file) from one source to one destination, it is becoming increasingly desirable to communicate the same information from one source to multiple destinations. For example, it is common for many recipients to view the same information, such as streaming video, originating at a single Internet web site.
One technique that permits information to be communicated between a plurality of sources and destinations is called “multicasting”. As an example, multicasting, as is supported by the Internet Protocol (IP), has been defined as follows: “IP Multicast is the efficient transmission of an IP datagram to a set of zero or more hosts identified by a single IP destination address.” (Deering, 1989). This will now be discussed in greater detail.
(IP) MULTICASTING
IP (and other types of) multicast efficiently supports one-to-many and many-to-many transmission by enabling sources to send a single copy of a message to multiple recipients (indirectly identified by a single IP class-D multicast address) who explicitly want to receive the information. This mechanism is far more efficient than sending multiple messages to each recipient simultaneously or broadcasting the message to all nodes on the network. IP multicasting is a natural solution for multi-party conferencing because of the efficiency of the data distribution trees (spanning trees), with data being replicated in the network at appropriate points rather than in end-systems.
Multicasting is based on a series of specific protocols that “ride on top” of the existing ones to efficiently distribute data to all interested parties. With IP multicast, receivers do not need to know who or where the senders are in order to receive traffic from them. Senders never need to know who the receivers are. Neither senders nor receivers need to care about the network topology because the network optimizes delivery.
Multicast is a receiver-based concept; receivers join a particular multicast session group by using a protocol such as the Internet Group Management Protocol (IGMP) to inform a multicast router on their subnetwork of their intention. Traffic is then delivered to all members of that group by the network infrastructure. To verify current membership, the local multicast router periodically sends an IGMP host membership query to the “all-hosts” group. To avoid congestion that would otherwise occur if each member host were to respond to the query, each host delays transmission of its report by a random time interval. At the end of the time interval, the host sends its report only if it has not seen a report for the same group from another host. As a result, only one membership report is sent in response for each active group address, although many hosts may have memberships. IGMP may also be used to forward the group membership information from the local router to the other multicast routers.
For delivery of a multicast packet from the source to the destination nodes on other networks, multicast routers need to exchange the information they have gathered from the group membership of the hosts directly connected to them. There are many different algorithms and protocols for exchanging this routing information, such as Distance Vector Multicast Routing Protocol (DVMRP), Multicast extension to Open Shortest Path First (MOSPF), and Protocol Independent Multicast (PIM). Based on the routing information obtained through one of these protocols, whenever a multicast packet is sent out to a multicast group, multicast routers decide whether to forward that packet to their network(s) or not. Finally, the leaf router determines whether there is any member of that particular group on its physically attached networks based on the IGMP information and decides whether to forward the packet or not.
If the sender layers its information (e.g., video or audio) stream, different receivers can choose to receive different amounts of traffic and hence different qualities. To do this the sender must code the information as a base layer (the lowest quality that might be acceptable) and a number of enhancement layers, each of which adds more quality at the expense of more bandwidth. Where the information is video information, for example, these additional layers might increase the frame rate or increase the spatial resolution of the images or both. Each layer is sent to a different multicast group and receivers can individually decide how many layers to subscribe to.
FIG. 1 shows an example of an IP multicast scenario in which an information stream (e.g., a video stream) is sent to each of four recipients: a first client 101, a second client 103, a third client 105, and a fourth client 107. A first multicast router (MR1) 109 is capable of routing information between a source 111 and each of second (MR2) and third (MR3) multicast routers 113, 115. The first and second clients 101, 103 have joined the group by informing the second multicast router 113; and the third and fourth clients 105, 107 have done the same with the third multicast router 115. The first client 101 receives a base layer (packets denoted “A1”), such as one suitable for a codec optimized for wireless environments, whereas the second client 103 receives this base layer and an additional layer (packets denoted “A2”) for a better quality of service (e.g., a better video quality). The third and fourth clients 105, 107 each receive a different base layer of packets (e.g., a layer suitable for a wireline codec), denoted “B1”.
To achieve an efficient transmission, a spanning tree is constructed, that connects all members of the multicast group. Only one copy of a multicast message will pass over any link in the network (between the source server 111 and the first multicast router, MR1, 109), and copies of the message will be made only where paths diverge at a router (e.g., at the three multicast routers MR1109, MR2113 and MR3115). Note that the “merging’ of multicast streams at traffic replication points (such as MR1109, MR2113 and MR3115) involves complex algorithms.
More information about IP Multicasting can be found in Andrew S. Tanenbaum, Computer Networks, Third Edition, Prentice-Hall, New Jersey, 1996; and on the Internet at the website for “IP Multicast Initiative (IPMI)”: www.ipmulticast.com
Reliable Multicasting
IP multicast is unreliable (based on User Datagram Protocol, or “UDP”) and provides best effort delivery, which results in occasional packet drops. For many multicast applications that operate in real-time, such as audio and video, this may be acceptable (as long as the packet loss is within reasonable limits). However, for some applications (e.g., synchronization messages between replicas) it is necessary to ensure that no critical information is lost.
Some of the typical issues that reliable multicast protocols have to handle are the following:                Network overload when packet reception is confirmed (ACK) or packet loss is indicated (NACK), also called the ACK/NACK implosion effect. This is usually solved by aggregation mechanisms.        Group management; closed, open limited and open unlimited groups.        Congestion control        Scalability        
A variety of reliable protocols and frameworks (e.g. Reliable Multicast Framework) have been proposed for multicast data delivery. Unlike the unicast case where requirements for reliable, sequenced data delivery are fairly general, different multicast applications have widely differing requirements for reliability. For example, some applications require that delivery obey a total ordering while many others do not. Some applications have many or all the members sending data while others have only one data source. Some applications have replicated data, so several members are capable of transmitting a data item while for others all data originates at a single source. These differences all affect the design of a reliable multicast protocol. Some examples of reliable multicast protocols are:                Reliable Multicast Protocol (RMP)        Scalable Reliable Multicast (SRM)        Reliable Multicast Transport Protocol (RMTP)        Multicast File Transfer Protocol (MFTP)        
The RMT (Reliable Multicast Transport) Working Group in IETF expects to initially standardize different protocol instantiations for one-to-many multicast applications. See the website for the Reliable Multicast Transport (RMT) Working Group in IETF at www.ietf.org/html.charters/rmt-charter.htm/.
More information about reliable multicast can be found at, for example, the IP Multicast Initiative (IPMI) website: www.ipmulticast.com.
Real-Time Transport (Control) Protocol, RT(C)P
The Real-Time Transport Protocol (RTP) provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data over multicast or unicast network services. The functions provided by RTP include payload type identification, sequence numbering, timestamping, and delivery monitoring.
The data transport is augmented by a control protocol (RTCP), which is used to monitor the Quality of Service (QoS) and to convey information about the participants in an ongoing session. Each media stream in a conference is transmitted as a separate RTP session (with a separate RTCP stream). RTCP reports provide statistics about the data received from a particular source, such as the number of packets lost since the previous report, the cumulative number of packets lost, the inter-arrival jitter, and the like.
REPLICATION AND (QUORUM CONSENSUS) SYNCHRONIZATION
A service or resource is “replicated” when it has multiple logically identical instances appearing on different nodes in a system. A request for access to the resource can be directed to any of its instances. Several mechanisms are available to synchronize the different copies (also called replicas) and keep them consistent. In case of replication, a different service access point (e.g., IP address) is used for each service instance.
The main reasons for replicating services are the following:                Load distribution (service copied to multiple hosts)        Performance increase (service copied to multiple hosts and possibly closer to the actual client(s))        Availability (service copied to multiple hosts)        
Replication is typically used when all clients need write access to the whole service (or when the service cannot be split into separate entities).
Replica Synchronization
In the case of shared data via a network, participants may attempt to manipulate a shared object (almost) at the same time. Concurrent actions on a shared object may result in inconsistent views among users. Without careful coordination, a sequence of concurrent actions would soon cause different views of what is supposed to be the same shared data.
Replicated resources need to be kept synchronized/consistent/coherent; that is, any write access needs to be communicated to all the replicas. There are basically two approaches for such synchronization:
Master/slave strategy
With this approach there is one primary server, holding the master copy, and several secondary servers (for each replica). The master copy services all the update requests, whereas the slave replicas are updated (synchronized) by receiving changes from or by taking copies from the primary server. Clients can read data from both the master and the slave representatives.
The primary server may be flexible or fixed. In the case of a flexible primary server, writes can be done to any server. The corresponding server then takes the responsibility for updating all replicas. This procedure is also called Read-One-Write-All (ROWA). In the case of a fixed server (also called “simple ROWA”), all writes have to be done to that server. Although this mechanism has a central point of failure (the primary server), the centralized control makes it relatively easy to resolve conflicts between requests and to maintain consistency. Several enhancements have been defined for both the flexible and fixed primary server models.
Distributed update control (voting)
This approach is more robust than the master/slave strategy in that no central point of failure (master) is needed. The basic idea is to require clients to request and acquire the permission of multiple servers before either reading or writing a replicated file. The corresponding strategies are known as Quorum-Consensus (QC) mechanisms.
Several variations have been defined, such as:                Uniform Majority QC: permission from a majority of the servers is needed for each write and read access.        Weighted Majority QC: similar to Uniform Majority QC, but now a server may have more than one vote (e.g., reliable or high-speed servers).        Voting with ghosts: a dummy (ghost) server is used for each server that is down. The ghost may only join a write quorum. This mechanism makes sure that a write quorum consensus is still possible in case a few servers are down (since the write quorum often consists of most servers.)        
Many more mechanisms have been defined, The general strategy is always:                to reduce the size of the quorum (for write and read accesses) in order to speed up the synchronization process (and reduce the network communication); and,        to limit the impact of server failures (e.g., voting with host).        
A coherence protocol is a specific implementation of a coherence/synchronization model. There may be several protocols for a single model. Which protocol is best may depend on issues such as read/write ratios, the number of clients simultaneously accessing a service, and the like. The standard against which all models are measured is sequential consistency, which means that all processes see all memory references in the same order. Causal consistency, Pipelined Random Access Memory (PRAM) consistency, and processor consistency all weaken the concept that processes see all memory references in the same order. Another approach is that of weak consistency, release consistency, and entry consistency, in which memory is not consistent all the time, but the programmer can force it to become consistent by certain actions, such as entering or leaving a critical region.
In a Local Area Network (LAN) it is feasible to have a central coordinator taking care of the synchronization between the different replicas. However, in a Wide Area Network (WAN) this central approach is usually not feasible, due to the high latencies involved (takes too much time to update all the replicas) and the central point of failure. In a WAN there is therefore a need for a distributed approach. More details about synchronization strategies can be found in Andrew S. Tanenbaum, Distributed Operating Systems, Prentice-Hall, New Jersey, 1995; and Coulouris at al., Distributed Systems: Concepts and Design, Addison-Wesley, Wokingham, 1991.
With multicasting, the information is always sent to all clients that have registered for the corresponding multicasting group (and are listening to the multicast port). In the case of a closed multicasting group, the number of clients may be known.
A draft of the Internet Group Management Protocol, Version 3 (IGMPv3), which may be found on the Internet at http://search.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-04.txt, will add source selection possibilities, such as listening to some sources only or to all but a set of unwanted sources. However, there is a problem in that no mechanism is yet foreseen to enable one to multicast to only a subset of the membership hosts.
Sometimes (e.g., for QC synchronization) there may be a need to have a type of multicasting wherein one can define the size of the subgroup (out of the total multicasting group). This means that one defines the number of recipients of a certain multicast message. In the case of QC synchronization, one can define the number of recipients that should receive a certain synchronization message.
As described above, RTCP is used to convey information about the participants in an ongoing session. This information is provided end-to-end, that is, from the destinations to the source and only works in cases in which the RTP protocol is used for transport (usually real-time multimedia data).
A recent IETF draft (namely, “Ipv4 Option for Somecast”, available via the Internet at the following website: http://search.ietf.org/internet-drafts/draft-dhelder-somecast-00.txt) describes “Somecast”, which is a mechanism that includes up to nine destination addresses in an IP header and performs combined unicast routing as long as the destinations have to use the same links. When routers determine that a destination uses a different link, the packet is sent as a normal unicast. As also stated in the IETF draft, this solution is not scalable. Furthermore, it has drawbacks, such as the requirement that the source must already know all the destinations.
There is therefore a need for a mechanism that will enable the multicasting of messages to only a subgroup of a defined set of membership hosts.